Zoek trefwoord in element

Application Function

Naamgevingsconventies Gebruik: werkwoord. Voorbeeld: Factureren, Zoeken, Indexeren.

Application function

Description of a logical application that has a relationship with a certain data object. Logical applications are independent of the implementation and are often modeled with verbs or with terms ending on system. For example collaborate or collaboration system.

Application Function

Naamgevingsconventie Gebruik: zelfstandig naamwoord. Voorbeeld: Facturering, Zoek Indexering (ing-vorm).

Component or information system

Physical implementation or component within the ArchiMate domain that is used to describe applications that implement certain logical applications or application functions. For example the application process collaborate is implemented in the component SharePoint. Note that this can be a relatively complex elaboration in organizations with a fragmented application landscape.

Data governance

Data governance activities and application functions layers for maintaining qualities of the datasets

Data security

Application functions and activities for securing datasets and storage functionalities

Master Data Management and Governance

Application functionality that support data management and governance processes. Think about data quality processes, data ownership and data security policies etc.

Other Data Producers

Other MDM data producing application functions like the delivery of office files etc.

Register Data Production

Logical application function for the storage and transformation of master data in various source function and the data register function

Specific requirements

Specific requirments for specific application functions like specific transformations

Scenario model data collaboration

In this scenario the master data register collaborates with the various data producing application functions. This means that when data is modified in one of the systems these modifications are shared between all collaborating functions. Therefore the integration between these data producers is essential in this scenario An interesting scenario in this is where the Data Register is only used as a key store or key cabinet and the detailed data is kept in the other source systems Advantages - Data is gathered directly from source systems and thus it is always accurate and real time. - Data can be stored within the source systems in a specific format supporting the business processes within these systems - Differences in availability between consumers and sources can be handled by the Data Register - Reuse of screens, workflows and validations in the source systems - Data standardization within the Data Register - Introduction of a key store or key cabinet. Disadvantages - Managing the synchronization between systems is an extra piece of work and complexity. - Replication of data - Complex data transformations from sources to register and back

Scenario model data registry

In this scenario there is only one master data producing application. That is the data register. It can also be one of the existing source systems. All other applications are consuming this data from the data register and use this in their application processes. This includes the application functions for ERP and geo etc. Advantages - The service design is directly mapped in the data register. - Possibility to standardize the information model and service interfaces - Verification and business rules are implemented only in the dasset data register. - Real time alignment of the data only upon read/request - High availability only necessary for the data register. - Eventually no replication of data (depends on the maturity of the consuming systems) Disadvantages - Any change in data model in consumers leads to change in service, this should be aligned or require a large standardized datamodel in the service interface. - Information provisioning to applications needs to be redesigned which is a lot of work - Redesign of the full application landscape - High demand in performance and availability for the data register - Introduction of a single point of failure so extra non functional requirements in AIC

Scenario models consumer perspective

In this master data consumer model a limited view of the relevant architectural entities are displayed. Here you see a high level model of register data consumption. Via different application functions data is consumed. For example via user interfaces like reports, portals, geo viewers etc data is directly consumed by various end users. A detailed inventarization of these end users and user interfaces will be modeled.

Transformation generic ABB

Description of the generic aspectis of the transformation application function. This has the following elements - Data sources - Transformation functions - Data targets - Data or object modeling functions